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TRANSPARENT ACCESS AUTHENTICATION IN GPRS CORE NETWORKS 


The present invention relates to a method and system for 
transparent access authentication in 2G and 2.5G Mobile 
Access Networks. This includes communication networks of the 
GSM- , GPRS- and UMTS-standard well known to. skilled persons. 

m 

< ■ • 

In standardisation of Universal Mobile Telecommunication 
System (UMTS Rel.5) comprehensive means are foreseen to 
perform authentication on the application layer with no need 
to interwork with the underlying radio and transport ■ 

* 

networks. The mechanisms are- based on- the assumption that a 
specific environment is prepared .for deployment of IP 
Multimedia Subsystem ("IMS ) services. It includes the use of 
IMS' SIM (ISIM) application, which in turn requires 
Re 1.99UICC',s in. the ' connected end devices to handle the 
authentication and key agreement (AKA) . 

•In case of deployment of IMS and IMS based services in a 
network environment which is characterised by the use of SIM 
cards, the standardised authentication mechanism will not be 

» * . 

applicable. 

It is the object of the invention to provide method and 

* • 

system for transparent access authentication which allow it • 
to run authentication transparently to the end device, 
without requiring proprietary extiensions and functions on 
network or client side . 

■ 

i 

• • • 

This object is achieved by providing a method and .system 1 

• ■ 

as described in the independent claims. 
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Other features which are considered to be characteristic 
for the invention are set forth in the dependent claims. 

• * 

» 

The present invention describ.es a. method for application 
layer authentication of subscribers, connected to the 
authenticating network domain by a 26 or 2 . 5G General Packet 
Radio Service (GPRS) core network or a 3G UMTS network. The 
authentication will be based on data which is assembled by . 
the network layer during ; establishment of a PDP context in . 
GPRS networks. This information is secured by standard SIM 
card application. As the same mechanisms are used for 
authentication in 3G networks, the further described 
mechanism is also applicable there. No standard would be 
touched in any way while using a 2G or 2. 5G- access network-, 
because no authentication on- application layer is foreseen in 
the' standard. For UMTS' Rel.5 standards and following, the 
standard foresees specific methods. The use of the further 
described method, would be . pqss.ibl_e y _,al though the standardised 
•authentication mechanism needs to be switched off. Switching 
off the standardised authentication mechanism could be 
interpreted as standard sensitive, but subsequent use of the 
further described"mechanism would be standard compliant* 
again. 

Further, a migration path to UMTS Rel.5 standardised, 
authentication and the concept for parallel use of both 

■ 

mechanisms is described. 


The invention will now be described in further detail with 
reference .to the drawings. 

Figure. 1 depicts the general architecture of the system for 
carrying out the invention; 
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Figure 2 depicts an embodiment of the invention with 
migration to IMS compliant architecture . 
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With reference to Figure .1, during PDP context establishment 
the Serving GPRS Support Node (SGSN) is authenticating the 
subscriber using the A3/A8 algorithm based on the end devices 
SIM card in case of GSM and 2 . 5G GPRS and EDGE access 
network. "C 

The Gateway GPRS Support Node 1 (GGSN) . receives a context 
creation request and queries a Radius (Registration) server 2 
(Remote Authentication" Dial-In User Service) to get an IP 
address .assigned for the particular PDP context. Within the 
context the Radius server 2 receives the. MSISDN and/or the 
IMSI of the subscriber.- So. in .'the session database 3 of the 
Radius server 2 there is stored for each PDP context a '.pair- ' 
of IP address and IMSI/MSISDN. Based on the tunnel endpoint 
ID (TEID) the GGSN 1 filters all . packets running through the 
PDP context once established, for the correct IP_ s.ouxce 
address. This means the GGSN 1 check's matching TEID/IP 
address pairs, thus preventing falsification of source 
addresses and so called "IP spoofing" for the complete 
lifecycle of the PDP context. The TEID unambiguously 
identifies a tunnel endpoint in. the receiving GTP-U (GPRS 
Tunnelling Protocol - User) or GTP-C (GPRS Tunnelling 

♦ * 

Protocol - Control) protocol entity. The receiving side, of a 

GTP tunnel locally assigns the TEID value for the 

transmitting side to use. The TEID values are exchanged 

between tunnel endpointW using GTP-C messages (or RANAP 

(Radio Access Network Application Part.) in the UTRAN (UMTS 

• • • • . 

30 terrestrial , Radio .Access Network 

In the application domain a subscriber database. 4 exists that 
stores all PublDs the subscriber is using in the. domain, 
referring if to his PrivID, which is unique in the respective 
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application. domain. The PrivID is correlated with an MSISDN 
and/or IMSI . i 

In the request the user gives his PrivID for registration. 
Upon receiving. the registration request, the registration 
proxy 5 queries the subscriber database 4 containing the 
subscribers IDs (both public and private) together with the 
MSISDN/IMSI. This data is stored in a table on the proxy 
server, platform. 

Subsequently the proxy server 5 queries the session .database 
3 of the Radius- server 2 in order to get the assigned IP 
address of that session and the IMSI/MSISDN already 
authenticated by the 'network's Home Location. Register (HLR). 
The- authentication of the- HLR guarantees further that the IP 
address can be considered to' be authenticated as well-. Also 
this information is stored in the table oh the- proxy server 
. platform. • . 


_Nqw the .P r °*y_, server 5 starts the authentication procedure 

• 

according to the invention. 


20 


First, the proxy server 5 checks IMSI/MSISDN from Radius 

■ ■ 

server 2 database 3 and' application domain database 4 "for 
match. If the pairs are' not' matching, the subscriber has 
tried to' register with an incorrect PrivID, which is not 
25 correlated with his IMSI/MSlSDN, if the pairs are matching 

• * • * 

the next step is performed,. 

• 

* « • 

Second step is; checking the. subscribers IP address in the IP 

* 

network layer, meaning in the IP packet overhead field for 
source address for match with the.. IP address assigned by the 
Radius server 3. As the. IP address was assigned to an 
IMSI/MSISDN-authenticated session/ also the IP address can b 
considered as authenticated. 

♦ ■ 

■ 
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If the pairs are not matching,, the subscriber used 
incorrect IP address, if the pairs are' matching th 
subsequent step is performed. 


. an 
e 


n 

The .proxy server 5 parses" the application layer for IP 
addresses given in the headers of e.g. SIP registration 
message, SDP message bodies, etc and checks for match with 
the IP address in, which was already checked for match with 
the IP address assigned by the Radius server 2. If the pairs 
are not matching the subscriber used incorrect signalling 
information, e. g. response addresses, etc. If the pairs are 
matching", the session' setup can be considered as 
authenticated. '• • ' 

■ • 

» 

< 

In .all subsequent messages arriving at the proxy server 5, it 

checks for match of IP' address in the IP packet overhead 

field for source- address with that in- the application layer 

protocol header- fields . and verifies the matching- pairs- 

against the IP address assigned by the Radius server 2. 

If PublDs are used in the following session, the PublDs are ■ 

checked against the PrivID which was stored in a table on th 

proxy server platform after. querying the application domains 
database 4 . 

■ • 

The described functionality gives the network" operatbr the 
opportunity to run -authentication transparently to the end- 
device, without requiring proprietary extensions and 
functions on network or client side . In case of SIP based 
signalling, the migration' to fully standard compliant UMTS 
Rel,5 mechanisms and a strategy for parallel operation is 
necessary, this will be described now. 
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As the IMS domain as Standardised. for UMTS Rel . 5 .will' include 
its own authentication mechanism, it is necessary to support 
a scenario where the ■ subscribers are migrating to ISIM 
enabled end-devices. To exploit the benefits of the 
standardised authentication mechanism, both, mechanisms have 
to be supported in parallel. 

This is done by an additional function that checks each 
incoming signalling message, first .for . the protocol, if 'itis ■ 
any other protocol than SIP, the session is routed to the 
proxy server 5 . 

With reference to Figure 2, the. same routing decision is taken 
if the message is based on SIP, but the client does not 

- 

support standardised UMTS Rel . 5 'authentication . If the client.- 

• * ♦ 

. does support standardised authentication method, e.g. is ISIm" 
enabled, the message is" routed to- the standard -compliant 
Proxy Call State Control Function (P-CSCF) . First trigger 'for 

* ■ 

routing decisions- is the protocol type, as ^described above. 
Further triggers could be the key exchange mechanism used for 
setting up the secured connection between UE and P-CSCF ( if 
the end device is starting key agreement, it can be • 
considered as standard compliant ' and the request is routed to 
the P-CSCF) , or other elements included in the UMTS Rel .5 
header as well as any private extension, which is, however, ' 
15 . possible- but not • necessary . If trigger points ■ available in 
signalling should be insufficient, also database lookups can 
be used to base routing decisions on. 


0 


30. 


The ..authentication -procedure is as follows 

First, a decision is required by which node P-CSCF 6 or proxy 
server 5 the register shall be routed - 

For this, a routing module 7 is provided which will be the 
standard entry point for all messages. The routing module 7 
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■ 

c • 

decides by evaluation of PrivID which node will handle the 

message. The, routing module 7 refers to" subdomains (e.g:. • 

user@gprs.tmo.de and use-r@tmo.umts.de) within the domain part 

of the Network Access Identifier (NAI) , see 3GPP 

specification 23.228. This requires that NAIs for 3G 

■ 

subscribers have to provide subdomains. 

« 

The routing module 7 shall set a routing entry, by using only 
the PrivID, subsequent messages shall be identified by the IP 
source address listed in the routing table. 

■ 

The routing module 7 identifies the responsible proxy 
function, i.e. proxy server 5 or P-CS.CF -6, by evaluating the 

• * • 

PrivID CURIs 's-ubdomains') This rises the request towards 
IMSI/MSISDN :and URIs to'be chosen according to this 
functionality . 

In case other protocols shall be . used .beside SIP, such as 
e.g. SMTP, HTTP, SOAP (.NET), etc, the proxy server. 5 must be 
extended, and. authenticate the .subscribers by use of the IP 
address, subsequently resolving the IMSI/MSISDN and matching 
of the- particular identifier of 'the protocol, which is stored 
in the subscriber profile of the subscriber database 4. This 
requires the population \ of the subscriber profile with the 

m * 

required data elements and extension of the routing module to 
enable protocol, dependent routing. 
25 .* 

In case . separate access networks are used-, the application 
platform' has to know which type of access' network is used to 

adapt service delivery accordingly. This requires that a 

■ 

change request has to be stated against the- SGSN to enable it 
30 to send the. access type to the GGSN which includes it in the 
. radius request, so the access network type will be available 
in the session database 3. This enables all applications to 
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request the access network type and use. it, e.g. for Qualit.y 
of Service (QoS) means. ■ 
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Abbreviations 

9 

* 

♦ 

■ • 

• 

2 . 5 G. 

second and half generation (e. a GPRS ttnnF\ 

• 

2G 

second generation (e. g. GSM) 

3G 

third generation (e. g.' UMTS) 

AKA 

« 

authentication and kev aareempni- 

* 

QC 

Circuit Switched 

IMS 

1 

IP multimedia subsystem 

» 

IMS I' 

* 

International Mobile Subscriber Identitv 

I SIM 

• 

IMS" SIM • • • - 

MS ISDN . 

* 

Mobile Station "ISDN Number- 

NAI ' 

Network Access Identifier ■ 

• 

•P-CSCF 

• • 

Proky-Call-State-Control-Function 

SIM (card) 

(GSM) Subscriber Identity Module (card) 

Sip • ■ 

Session Initiation Protocol 

* ■ * 

TEID 

• • 

Tunnel EndDoint ID 

* 

UE 

* ■ 

User Equipment 

UICC 

« 

UMTS TC C^rd " 

UMTS 

Universal: mobile telecommunication system 

. URI 

Uniform Ressource Locator 
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